Subject: Re: [spfbis] Barry Leiba's Discuss on draft-ietf-spfbis-4408bis-19: (with DISCUSS and COMMENT)

From: S Moonesamy <[email-masked]>
Date: Wed, 11 Sep 2013 05:04:11 -0700

Hello,

Could the SPFBIS WG please review the following?

Thanks,
S. Moonesamy (as document shepherd)

At 18:58 10-09-2013, Barry Leiba wrote:
>Barry Leiba has entered the following ballot position for
>draft-ietf-spfbis-4408bis-19: Discuss
>
>When responding, please keep the subject line intact and reply to all
>email addresses included in the To and CC lines. (Feel free to cut this
>introductory paragraph, however.)
>
>
>Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>for more information about IESG DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/
>
>
>
>----------------------------------------------------------------------
>DISCUSS:
>----------------------------------------------------------------------
>
>I have two very small points that I think are unclear, and important
>enough that we have to get them right, both regarding the check_host()
>function.  These should be really easy to clear up:
>
>-- Section 4.6 --
>
>    The check_host() function parses and interprets the SPF record to
>    find a result for the current test.  If there are any syntax errors
>    anywhere in the record, check_host() returns immediately with the
>    result "permerror", without further interpretation.
>
>I think you're trying to say that syntax checking is done before any
>evaluation, but you aren't saying it.  It matters, because
>implementations that make different choices in that regard won't get the
>same results from check_host() in all cases, as they're required to.
>Maybe this?:
>
>NEW
>    The check_host() function parses and interprets the SPF record to
>    find a result for the current test.  The syntax of the record is
>    validated first, and if there are any syntax errors anywhere in the
>    record, check_host() returns immediately with the result "permerror",
>    without further interpretation or evaluation.
>END
>
>-- Section 5.5 --
>
>I have to say that I'm not happy about the pseudocode here: what
>situation are we in when the pseudocode differs from the text?  Which
>wins?
>
>I already see a case where they differ: the new pseudocode says "if more
>than 10 sending-domain_names are found, use at most 10", and there's
>nothing of the sort in the text.
>
>Does the working group really think there's enough value in having
>pseudocode there that it's worth saying the same thing twice and relying
>on them to be truly the same?  And is it really worth it for mechanism
>that's not recommended for use?
>
>I strongly suggest making sure that the text says what you want it to,
>and removing the pseudocode.
>
>
>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>I have a bunch of editorial comments that I'd like you to consider.
>They're all non-blocking, but I think they'll improve the document, and
>I'll be happy to chat about them if you like.
>
>-- Section 2.5 --
>
>    Performing the authorization check other than using the MAIL FROM and
>    client address at the time of the MAIL command during the SMTP
>    transaction can cause problems, such as the following: (1) It might
>    be difficult to accurately extract the required information from
>    potentially deceptive headers; (2) legitimate email might fail
>    because the sender's policy had since changed.
>
>I found that to be awkwardly worded and hard to understand.  Please
>consider this rewrite:
>
>NEW
>    The authorization check is performed during the SMTP transaction
>    at the time of the MAIL command, and uses the MAIL FROM value and
>    the client IP address.  Performing the check at later times or
>    with other input can cause problems such as the following:
>
>    *  It might be difficult to accurately extract the required
>       information from potentially deceptive headers.
>
>    *  Legitimate email might fail the authorization check because
>       the sender's policy has since changed.
>END
>
>-- Section 2.6 --
>
>It would really read best if the subsections were worded to be parallel.
>As it stands, subsections 1, 3, 4, 6, and 7 are worded as "result X means
>Y", and subsections 2 and 5 are not.  Can you re-word 2 and 5 to be
>parallel to the others?
>
>Also, why are "neutral" and "fail" called "explicit statements", but
>"pass", for example, is not?
>
>-- Section 3 --
>
>    Each SPF record is placed in the DNS tree at the owner name it
>    pertains to, not a subdomain under it, such as is done with SRV
>    records [RFC2782].
>
>This looks like it's saying that SRV records are placed in subdomains,
>and I don't think that's what you mean.  Or is it?  In any case, it's not
>clear (and I know this text is from the original).
>
>Maybe this (which also avoids the two different "it"s)?:
>
>NEW
>    Each SPF record is placed in the DNS tree at the owner name it
>    pertains to, not in a subdomain under the owner name.  This is
>    similar to how SRV records [RFC2782] are done.
>END
>
>    The example in this section might be published via these lines in a
>    domain zone file:
>
>       example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all"
>       smtp-out.example.com. TXT "v=spf1 a -all"
>
>What does "smtp-out" have to do with anything?  It's not otherwise used,
>and it seems to contradict what you say about subdomains in the previous
>paragraph.
>
>-- Section 4 --
>
>    This description is not an API (Application Program Interface)
>    definition,
>
>Two total nits on this:
>1. You never use "API" other than here, so there's no need to define it,
>and
>2. the usual expansion of "API" is application programMING interface.
>I suggest, "This description is not an application programming interface
>definition, [etc]."
>
>-- Section 4.5 --
>
>    Starting with the set of records that were returned by the lookup,
>    discard records that do not begin with a version section of exactly
>    "v=spf1".  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 is discarded.
>
>Sure, and "v=spf1.0" doesn't match, and "v=spf11" doesn't match, and....
>Why is it necessary or desirable to single out "v=spf10" here?
>
>-- Section 4.6.4 --
>
>    SPF implementations MUST limit the total number of mechanisms and
>    modifiers ("terms") that cause any DNS query to 10 during SPF
>    evaluation.  Specifically, the "include", "a", "mx", "ptr", and
>    "exists" mechanisms as well as the "redirect" modifier count against
>    this collective limit.  The "all", "ip4", and "ip6" mechanisms do not
>    count against this limit.  If this number is exceeded during a check,
>    a "permerror" MUST be returned.  The "exp" modifier does not count
>    against this limit because the DNS lookup to fetch the explanation
>    string occurs after the SPF record evaluation has been completed.
>
>When I read this, I start feeling like I'm being read the rules for
>Fizzbin <http://en.wikipedia.org/wiki/Fizzbin#Fizzbin>.  I would
>appreciate it if this was re-worded so that there are two clear lists
>here: the terms that are included in the "limit of 10", and the terms
>that are not (and are, presumably, unlimited).  Perhaps something like
>this:
>
>NEW
>    Some mechanisms and modifiers (collectively, "terms") cause DNS
>    queries at the time of evaluation, and some do not.  The following
>    terms cause DNS queries: <list goes here>.  SPF implementations
>    MUST limit the total number of those terms to 10 during SPF
>    evaluation, to avoid unreasonable load on the DNS.  If this limit
>    is exceeded, the implementation MUST return "permerror".  The other
>    terms (<list goes here>) do not cause DNS queries at the time of
>    SPF evaluation, and their use is not subject to this limit.
>END
>
>If you think it's necessary (I don't):
>
>NEW+
>    The other
>    terms (<list goes here>) do not cause DNS queries at the time of
>    SPF evaluation (the "exp" modifier causes a lookup at a later time),
>    and their use is not subject to this limit.
>END
>
>Then in the next two paragraphs, I think it would improve clarity to make
>a change such as this:
>
>OLD
>    When evaluating the "mx" mechanism, the number of "MX" resource
>    records queried is included in the overall limit of 10 mechanisms/
>    modifiers that cause DNS lookups described above.  The evaluation of
>    each "MX" record MUST NOT result in querying more than 10 address
>    records,
>NEW
>    When evaluating the "mx" mechanism, the number of "MX" resource
>    records queried is included in the overall limit of 10 mechanisms/
>    modifiers that cause DNS lookups described above.  In addition to
>    that limit, the evaluation of each "MX" record MUST NOT result in
>    querying more than 10 address records,
>END
>
>(And similarly for the "ptr" paragraph.)  I know you say this in a
>paragraph of its own ("These limits are per mechanism..."), but it's
>helpful if people can understand things as they read them, and then to
>emphasize it later... rather than having them scratch their heads for a
>few paragraphs until they get to it.
>
>-- Section 4.7 --
>
>    It is better to use either a "redirect" modifier or an "all"
>    mechanism to explicitly terminate processing.  Although the latter
>    has a default (specifically "?all"), it aids debugging efforts if it
>    is explicitly provided.
>
>I'm not sure what "the latter has a default" is trying to say.  Do you
>mean that "?all" is the default if you fall off the end, but you
>shouldn't rely on that?  Or do you mean that if you say "all", then
>"?all" is taken as the default (I would think "all" would mean "+all")?
>Will you try re-wording this, please?
>
>-- Section 5 --
>
>What does "(do not publish)" mean next to "ptr" in the sender mechanisms
>list?  Ah; I see; it matches the "do not use" in Section 5.5.  You should
>probably change this to "(do not use; see the note in Section 5.5)".
>
>It would help, I think, to add to the end of the second paragraph, "The
>basic mechanisms are as follows:", and to the end of the third paragraph,
>"The designated sender mechanisms are as follows:".  Otherwise, there are
>just these disembodied lists, and the reader has to infer those
>introductions.
>
>-- Section 5.1 --
>
>    Mechanisms after "all" will never be tested.  Mechanisms listed after
>    "all" MUST be ignored.  Any "redirect" modifier (Section 6.1) MUST be
>    ignored when there is an "all" mechanism in the record.
>
>This says that the redirect in the following record will be ignored:
>
>    v=spf1 redirect=_spf.example.com +all
>
>That's sufficiently odd that it should be called out explicitly, perhaps
>by adding "regardless of the relative ordering of the terms" to the last
>sentence in the quote.
>
>-- Section 5.2 --
>
>    3.  The recursive evaluation returns either match, not match, or an
>        error.  If it matches, then the appropriate result for the
>        include: mechanism is used (e.g. include or +include produces a
>        "pass" result and -include produces "fail").
>
>    4.  If there is no match, the parent check_host() resumes processing
>        as per the table below, with the previous value of <domain>
>        restored.
>
>A few things here:
>
>1. Nit: "either" is for two things; for more than two, please remove the
>word "either" (or replace it with "one of", but that seems awkward
>here).
>
>2. "If it matches" is not parallel to "returns match", and similarly for
>"if there is no match".
>
>3. You don't say what happens if the recursive evaluation returns an
>error.  Unfortuately, "no match" and "not match" are sufficiently similar
>to be confused.
>
>I suggest this:
>
>NEW
>    3.  The recursive evaluation returns match, not match, or an
>        error.
>
>    4.  If it returns match, then the appropriate result for the
>        include: mechanism is used (e.g., include or +include produces
>        a "pass" result and -include produces "fail").
>
>    5.  If it returns not match or an error, the parent check_host()
>        resumes processing as per the table below, with the previous
>        value of <domain> restored.
>END
>
>    The "include" mechanism is intended for crossing administrative
>    boundaries.  For example, if example.com and example.org were managed
>    by the same entity, and if the permitted set of hosts for both
>    domains was "mx:example.com", it would be possible for example.org to
>    specify "include:example.com", but it would be preferable to specify
>    "redirect=example.com" or even "mx:example.com".
>
>The text you eliminated here provided a buffer that's no longer there,
>making the "For example," very odd.  You talk about crossing admin
>boundaries and immediately follow it with an example that does NOT.  I
>think it would be better to put a sentence in to restore that buffer --
>perhaps, "When remaining within one administrative authority, "include"
>is usually not the best choice."
>
>-- Section 5.5 --
>
>    This mechanism SHOULD NOT be published.  See below for discussion.
>
>It's quite a bit below.  I suggest "See the note at the end of this
>section for more information."  It might even be worth putting that note
>into a Section 5.5.1, so it's highlighted and more easily cited.
>
>-- Section 6 --
>
>    Unrecognized modifiers MUST be ignored no matter where in a record,
>    or how often.
>
>This is missing a couple of words:
>
>NEW
>    Unrecognized modifiers MUST be ignored no matter where in a record
>    they appear, or how often.
>END
>
>    For clarity, any "redirect" modifier SHOULD appear as the very last
>    term in a record.
>
>I don't usually recommend repeating things, but one thing from earlier
>probably does bear repeating here:
>
>NEW
>    For clarity, any "redirect" modifier SHOULD appear as the very last
>    term in a record.  Any "redirect" modifier MUST be ignored if there
>    is an "all" mechanism anywhere in the record.
>END

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Sep 2013 07:07:33 -0700

On Wed, Sep 11, 2013 at 5:04 AM, S Moonesamy <[email-masked]> wrote:

>
>
>> ------------------------------**------------------------------**
>> ----------
>> DISCUSS:
>> ------------------------------**------------------------------**
>> ----------
>>
Yep.

>> and removing the pseudocode.
I've written drafts (e.g., RFC5451) that contain prose and an algorithm
description for the same thing, so it's possible to get this right.  I'm
not sure it's necessary here, so I agree we should consider dumping it.

Will review the comment stuff later today.

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Wed, 11 Sep 2013 11:08:01 -0400

> description for the same thing, so it's possible to get this right.  I'm not
> sure it's necessary here, so I agree we should consider dumping it.

To be clear: I agree with you that it's possible to get it right and
sometimes valuable.  I'm suggesting removing it because I don't think
it's valuable here.  Thanks for considering that.

Barry

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 11 Sep 2013 12:59:33 -0400

> >>    without further interpretation or evaluation.

I think this change is fine.  Should I make it?

> Will review the comment stuff later today.

I think we can just remove it.   Looking it over, I don't think it adds much, 
if anything.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Sep 2013 10:23:57 -0700

Seems reasonable.

>> Y", and subsections 2 and 5 are not.  Can you re-word 2 and 5 to be
Seems reasonable.

>> "pass", for example, is not?
I agree, "pass" should be.

>>    similar to how SRV records [RFC2782] are done.
Seems reasonable.

>> and it seems to contradict what you say about subdomains in the previous
Hmm.  Someone else will have to comment on this one.

>> I suggest, "This description is not an application programming interface
Seems reasonable.

>> Why is it necessary or desirable to single out "v=spf10" here?
I think "v=spf1.0" is actually the better (and perhaps intended) example,
meaning "don't just stuff the part after 'spf' through a number parser and
make sure 1 comes out".

>> Fizzbin <http://en.wikipedia.org/wiki/**Fizzbin#Fizzbin<http://en.wikipedia.org/wiki/Fizzbin#Fizzbin>>.
>>  I would
I like the new text, and prefer the second bit be included.

>> few paragraphs until they get to it.
+1 to that part too.

>> Will you try re-wording this, please?
The former ("?all" is implicit if you fall off the end).  Suggest:

It is better to use either a "redirect" modifier or an "all" mechanism to
explicitly terminate processing.  Although there is in effect a "?all"
implicit at the end of every record, it ads debigging efforts when it is
explicitly provided.

>> probably change this to "(do not use; see the note in Section 5.5)".
Seems reasonable.

>> just these disembodied lists, and the reader has to infer those
Sure.

Yep.

>>        value of <domain> restored.
+1.

>> is usually not the best choice."
Sure.

>> into a Section 5.5.1, so it's highlighted and more easily cited.
+1.

>>    they appear, or how often.
+1.

>>    is an "all" mechanism anywhere in the record.
Seems reasonable.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Wed, 11 Sep 2013 13:45:48 -0700

Hi Scott,

For context, Barry's DISCUSS message is at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg04109.html  I 
went through the comments sent by Murray (Murray, thanks for doing that).

>and it seems to contradict what you say about subdomains in the previous

Could you please respond to the above?

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 11 Sep 2013 16:54:23 -0400

Will do shortly. 

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 11 Sep 2013 17:38:27 -0400

> >>       the sender's policy has since changed.

Agreed.

> >> Y", and subsections 2 and 5 are not.  Can you re-word 2 and 5 to be

Agreed.

Yep.

> >>    similar to how SRV records [RFC2782] are done.

Agreed.

> Hmm.  Someone else will have to comment on this one.
 
Those are just two examples, but the preceding text is poorly worded (I 
checked and it's no better in RFC 4408).  How about this instead, to clarify:

   The example in this section (plus an additional SPF record for
   smtp-out.example.com) might be published via these lines in a
   domain zone file:

> >> I suggest, "This description is not an application programming interface

Agreed.

> meaning "don't just stuff the part after 'spf' through a number parser and

The intent here is to show that you have to look at least one character past 
"v=spf1" to know if it's an SPF record or not.  It's an example.  As such, it 
doesn't matter much wrt the point if it's "v=spf10", "v=spf1.0", or or 
"v=spf1hatespf".  None of those start SPF records.  What's there is unchanged 
from RFC 4408.  I don't seem much of a point in changing it, but if others 
think 1.0 is better than 10, I don't mind.

> >> Fizzbin
> >> <http://en.wikipedia.org/wiki/**Fizzbin#Fizzbin<http://en.wikipedia.org/
> >> wiki/Fizzbin#Fizzbin>>.>> 
> >>  I would
> >> 

If we change, and I think that's reasonable, the second bit should definitely 
be included.  "exp" not counting in the 10 has confused people and we should 
be explicit about it.

Seems reasonable.

> implicit at the end of every record, it ads debigging efforts when it is

How about:

   It is better to use either a "redirect" modifier or an "all" mechanism to
   explicitly terminate processing.  Although there is an implicit "?all" at
   the end of every record that is not explicitly terminated, it aids
  debugging efforts when it is explicitly provided.

> >> probably change this to "(do not use; see the note in Section 5.5)".

OK.

> >> just these disembodied lists, and the reader has to infer those

Agreed.

> >> by adding "regardless of the relative ordering of the terms" to the last

OK.

> >>        value of <domain> restored.

I think this is fine.

> >> is usually not the best choice."

Agreed.

> >> into a Section 5.5.1, so it's highlighted and more easily cited.

OK.  Someone let me know which way I should do it.  I'm OK with either.

> >>    they appear, or how often.

OK.

> >>    is an "all" mechanism anywhere in the record.

OK.

Thanks for the detailed review and msk's comments on the comments.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Wed, 11 Sep 2013 14:51:14 -0700

Hi Barry,

Scott and Murray are okay with the text you suggested to address the 
DISCUSS ( http://www.ietf.org/mail-archive/web/spfbis/current/msg04114.html ).

The SPFBIS WG seems okay with most of the text you suggested as 
COMMENT.  There are some comments from Scott (see below) for the rest.

Regards,
S. Moonesamy

At 14:38 11-09-2013, Scott Kitterman wrote:
> <http://en.wikipedia.org/wiki/**Fizzbin#Fizzbin<http://en.wikipedia.org/>

---

From: Barry Leiba <[email-masked]>
Date: Wed, 11 Sep 2013 19:08:18 -0400

> Scott and Murray are okay with the text you suggested to address the DISCUSS
> ( http://www.ietf.org/mail-archive/web/spfbis/current/msg04114.html ).
>
> The SPFBIS WG seems okay with most of the text you suggested as COMMENT.
> There are some comments from Scott (see below) for the rest.

Thanks, SM, for brokering.  As this is now going directly to the WG,
Scott, Murray, or others can respond directly at this point.

>       smtp-out.example.com. TXT "v=spf1 a -all"

Well, OK... and it is a non-blocking comment, remember.  But what
value is there in including that second line at all?  You're giving a
specific example in that section, and this is supporting that example.
 If this were a general section of multiple examples, maybe.  I think
you should just strike it.

But, again: non-blocking comment.  Do as you think best, and this is
the last I'll say about this.

>>> Sure, and "v=spf1.0" doesn't match, and "v=spf11" doesn't match,
>>> and.... Why is it necessary or desirable to single out "v=spf10" here?
>>
> The intent here is to show that you have to look at least one character
> past "v=spf1" to know if it's an SPF record or not.  It's an example.  As
> such, it doesn't matter much wrt the point if it's "v=spf10", "v=spf1.0", or
> or "v=spf1hatespf".  None of those start SPF records.  What's there is
> unchanged from RFC 4408.  I don't seem much of a point in changing it,
> but if others think 1.0 is better than 10, I don't mind.

Again, non-blocking, so, again, do as you think is best, and this will
be my last comment on it.

It just seems bizarre to me to pick one particular invalid value and
say that it doesn't match and is discarded.  The point is that
*anything* that isn't exactly "v=spf1" doesn't match and is discarded.

Let me suggest a specific text change.  Take it, leave it, or change
it -- you don't need to bat it around with me further.

NEW
Starting with the set of records that were returned by the lookup,
discard records that do not begin with a version section of exactly
"v=spf1".  The version section is terminated by either an SP character
or the end of the record; if "v=spf1" is followed by any character
other than SP, it does not match and that record is discarded.
END

> be included.  "exp" not counting in the 10 has confused people and we
> should be explicit about it.

Kewl; thanks.

>>   debugging efforts when it is explicitly provided.

Also nice.

> OK.  Someone let me know which way I should do it.  I'm OK with either.

I kind of like the separate section, but it's a smaller change to just
leave the note and say "see the note."  Unless anyone feels strongly
that a separate section is worth the trouble, I suggest just pointing
people to the note explicitly.

And again, thanks for all the work on this, and for considering my
fairly long list.

Barry

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Sep 2013 18:27:05 -0700

> you should just strike it.

I agree actually.  I don't know what this adds, unless we want to explain
what the use of the second record would be (e.g., there's an intent to say
with a MAIL FROM domain of smtp-out.example.com is much more tightly
constrained for some reason).  If we don't want to describe the use case,
we should strike the second record.
NEW

> other than SP, it does not match and that record is discarded.

That'd be fine with me too.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 12 Sep 2013 01:50:39 -0000

>we should strike the second record.

I'd think that smtp-out.example.com is the host name of the SMTP server so it appears
in the EHLO, and SPF uses it for bounces with null senders.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 12 Sep 2013 00:34:44 -0400

On Wednesday, September 11, 2013 19:08:18 Barry Leiba wrote:
> > DISCUSS (
> > http://www.ietf.org/mail-archive/web/spfbis/current/msg04114.html ).
> > 
> > checked and it's no better in RFC 4408).  How about this instead, to
> > 
> > clarify:

I think that makes sense.  I removed it.

> > such, it doesn't matter much wrt the point if it's "v=spf10", "v=spf1.0",
> > or or "v=spf1hatespf".  None of those start SPF records.  What's there is

Thanks.  I changed the existing text to have the sentence start, "As an 
example, ..." so that it's clear this is exemplary.  I think that is the 
minimal change that should resolve this.

> > If we change, and I think that's reasonable, the second bit should
> > definitely be included.  "exp" not counting in the 10 has confused people
> > and we should be explicit about it.
> 
> Kewl; thanks.

Did that.

> >>   debugging efforts when it is explicitly provided.

Done.

> people to the note explicitly.

I just pointed at the note.

> And again, thanks for all the work on this, and for considering my

Thanks for the feedback.  I'll post a new diff shortly.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 12 Sep 2013 00:58:08 -0400

On Wednesday, September 11, 2013 17:38:27 Scott Kitterman wrote:
> > >> and....
> "v=spf1" to know if it's an SPF record or not.  It's an example.  As such,
> it doesn't matter much wrt the point if it's "v=spf10", "v=spf1.0", or or
> "v=spf1hatespf".  None of those start SPF records.  What's there is
> unchanged from RFC 4408.  I don't seem much of a point in changing it, but
> if others think 1.0 is better than 10, I don't mind.
> 
> > >> -- Section 4.6.4 --
> > >> 

I just realized the update to the draft I just posted doesn't include any of 
these changes.  They are not (now) forgotten.  I'll included them next time I 
update things.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 23 Sep 2013 00:26:53 -0400

Finally getting back to addressing additional comments.  I have it in my notes 
that we hadn't addressed the comment part of this in -20.  Based on the 
comments I previously sent to the list, I'm attaching my proposed changes (so 
far - there are more messages needing processing) for -21.  Additional 
comments embedded below.

Scott K

Done.

Done.

Done.

Done.

>       smtp-out.example.com. TXT "v=spf1 a -all"

Already fixed in -20.

Done.

> if others think 1.0 is better than 10, I don't mind.

There was already a change for this in -20.

Done.

Done.

> debugging efforts when it is explicitly provided.

This was changed in -20.

Done.

Done.

Done.

Done.

Done.

> OK.  Someone let me know which way I should do it.  I'm OK with either.

The first option was done in -20.

Done.

> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis

---

From: S Moonesamy <[email-masked]>
Date: Tue, 24 Sep 2013 09:00:24 -0700

Hi Barry,
>far - there are more messages needing processing) for -21.  Additional

Please see the comments from Scott Kitterman below (Thanks, 
Scott).  The attachment which I am not forwarding can be found at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg04212.html

Regards,

> <http://en.wikipedia.org/wiki/**Fizzbin#Fizzbin<http://en.wikipedia.org> > >> /
> mechanism to

---

From: Barry Leiba <[email-masked]>
Date: Tue, 24 Sep 2013 13:57:40 -0400

>> Finally getting back to addressing additional comments.  I have it in
>> my notes that we hadn't addressed the comment part of this in -20.
>> Based on the comments I previously sent to the list, I'm attaching my
>> proposed changes (so far - there are more messages needing
>> processing) for -21.  Additional comments embedded below.
>
> Please see the comments from Scott Kitterman below (Thanks, Scott).  The
> attachment which I am not forwarding can be found at

Yes, thanks for addressing this stuff.  When -21's posted, after all
the changes are in, I'll review it and see where we are.  I'm sure
it'll have everything important taken care of.

Barry