Skip to main content

Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
draft-ietf-spfbis-4408bis-21

Revision differences

Document history

Date Rev. By Action
2014-04-23
21 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2014-03-31
21 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2014-03-11
21 (System) RFC Editor state changed to RFC-EDITOR from AUTH
2014-03-10
21 (System) RFC Editor state changed to AUTH from EDIT
2014-01-24
21 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2014-01-24
21 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2014-01-23
21 (System) IANA Action state changed to Waiting on Authors from In Progress
2014-01-21
21 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent
2014-01-19
21 (System) IANA Action state changed to In Progress
2014-01-17
21 (System) RFC Editor state changed to EDIT
2014-01-17
21 (System) Announcement was received by RFC Editor
2014-01-17
21 Amy Vezza State changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed
2014-01-17
21 Amy Vezza IESG has approved the document
2014-01-17
21 Amy Vezza Closed "Approve" ballot
2014-01-17
21 Amy Vezza Ballot approval text was generated
2014-01-17
21 Pete Resnick Ballot writeup was changed
2013-09-26
21 Cindy Morgan State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation::AD Followup
2013-09-26
21 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2013-09-26
21 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to Yes from No Objection
2013-09-26
21 Barry Leiba
[Ballot comment]
Version -21 addresses all of my non-blocking comments; thanks very much for considering these and dealing with them!

The RFC Editor note takes …
[Ballot comment]
Version -21 addresses all of my non-blocking comments; thanks very much for considering these and dealing with them!

The RFC Editor note takes care of the bits that got left out of -21, and it addresses my DISCUSS.  So all is now clear.
2013-09-26
21 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss
2013-09-26
21 Pete Resnick Ballot writeup was changed
2013-09-26
21 Barry Leiba
[Ballot discuss]
UPDATED for -21: It seems that resolutions for the DISCUSS points got left out of the update.  :-(

-------------------------------------------------------

I have two very …
[Ballot discuss]
UPDATED for -21: It seems that resolutions for the DISCUSS points got left out of the update.  :-(

-------------------------------------------------------

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.
2013-09-26
21 Barry Leiba Ballot discuss text updated for Barry Leiba
2013-09-26
21 Barry Leiba
[Ballot discuss]
UPDATED for -21: It seems that resolutions for the DISCUSS points got left out of the update.  :-(
-------------------------------------------------------
I have two very …
[Ballot discuss]
UPDATED for -21: It seems that resolutions for the DISCUSS points got left out of the update.  :-(
-------------------------------------------------------
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.
2013-09-26
21 Barry Leiba [Ballot comment]
Version -21 addresses all of my non-blocking comments; thanks very much for considering these and dealing with them!
2013-09-26
21 Barry Leiba Ballot comment and discuss text updated for Barry Leiba
2013-09-25
21 Scott Kitterman New version available: draft-ietf-spfbis-4408bis-21.txt
2013-09-23
20 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2013-09-22
20 Adrian Farrel
[Ballot comment]
I am balloting No Objection based on this work having no obvious impact on the Routing infrastructure, and the more detailed reviews and …
[Ballot comment]
I am balloting No Objection based on this work having no obvious impact on the Routing infrastructure, and the more detailed reviews and comment of the other ADs (who are more knowledgeable about this material).
2013-09-22
20 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2013-09-20
20 Meral Shirazipour Request for Telechat review by GENART Completed: Ready. Reviewer: Meral Shirazipour.
2013-09-19
20 Jean Mahoney Request for Telechat review by GENART is assigned to Meral Shirazipour
2013-09-19
20 Jean Mahoney Request for Telechat review by GENART is assigned to Meral Shirazipour
2013-09-13
20 Pete Resnick [Ballot Position Update] Position for Pete Resnick has been changed to Yes from Discuss
2013-09-12
20 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-09-12
20 Scott Kitterman IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2013-09-12
20 Scott Kitterman New version available: draft-ietf-spfbis-4408bis-20.txt
2013-09-12
19 Cindy Morgan Telechat date has been changed to 2013-09-26 from 2013-09-12
2013-09-12
19 Cindy Morgan State changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2013-09-12
19 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Phillip Hallam-Baker.
2013-09-12
19 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2013-09-12
19 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2013-09-12
19 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2013-09-12
19 Sean Turner
[Ballot comment]
Should s11.3 also provide a mitigation via a reference for the spoofed DNS?  Right now it just points to the DNS threats RFC.  …
[Ballot comment]
Should s11.3 also provide a mitigation via a reference for the spoofed DNS?  Right now it just points to the DNS threats RFC.  I guess the reader can infer they should use DNSSEC if they're worried but adding a pointer to the right RFC would be better.  Something as simple as adding "... and see [RFCXYZ] for a countermeasure" or something like that.
2013-09-12
19 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner
2013-09-12
19 Benoît Claise
[Ballot comment]
disclaimer: I've only reviewed the changes compared to the RFC 4088.

Regarding "Appendix J.  Change History":
  NOTE TO RFC EDITOR: Changes …
[Ballot comment]
disclaimer: I've only reviewed the changes compared to the RFC 4088.

Regarding "Appendix J.  Change History":
  NOTE TO RFC EDITOR: Changes since RFC 4408 (to be removed prior to
  publication)

Personally, I like it when the new RFC has one section summarizing the changes compared to the initial RFC.
This would be a mix of:
  Appendix J.  Change History", but no needs to mention the editorial changes
  Appendix C.  Changes in implementation requirements from RFC 4408

Regards, Benoit
2013-09-12
19 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2013-09-12
19 Stephen Farrell
[Ballot comment]

- 4.1: given that recursion is allowed and that you have
overall limits on how many DNS transactions can be done,
is the …
[Ballot comment]

- 4.1: given that recursion is allowed and that you have
overall limits on how many DNS transactions can be done,
is the "transactions-remaining" value also an implicit
parameter of a check_host() call? This is only a comment
since check_host is not a formal API but it'd seem to make
it easier to get right if you make that implicit parameter
explicit. Or do the limits apply to each call as you
recurse?  That wasn't entirely clear to me.

- I didn't get appendix D at all - what's that do?

- Appendix E.1, 2nd bullet: what's that? I think it needs
a reference if you want it to be understood.
2013-09-12
19 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2013-09-12
19 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2013-09-12
19 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2013-09-11
19 Richard Barnes [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes
2013-09-11
19 Stewart Bryant [Ballot comment]
I am voting no objection on the basis of a quick scan indicating that there are no implications for the routing system.
2013-09-11
19 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant
2013-09-10
19 Barry Leiba
[Ballot discuss]
I have two very small points that I think are unclear, and important enough that we have to get them right, both regarding …
[Ballot 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.
2013-09-10
19 Barry Leiba
[Ballot 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, …
[Ballot 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 .  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: .  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 () 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 () 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
      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  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
2013-09-10
19 Barry Leiba [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba
2013-09-09
19 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2013-09-07
19 Spencer Dawkins
[Ballot comment]
I'm a No-Obj on the document itself, but I look forward to seeing the text mentioned in Pete's Discuss about how obsoleting Type …
[Ballot comment]
I'm a No-Obj on the document itself, but I look forward to seeing the text mentioned in Pete's Discuss about how obsoleting Type 99 in favor of TXT records is not going to be a precedent for other protocols ...
2013-09-07
19 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2013-09-07
19 Pete Resnick Note added 'You may wish to view the summary on the IETF list: https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=72183&tid=1378561974'
2013-09-07
19 Pete Resnick State changed to IESG Evaluation from Waiting for AD Go-Ahead
2013-09-07
19 Pete Resnick
[Ballot discuss]
Holding my own DISCUSS:

Text needs to be created (probably for section 3.1) to better describe the reason this document settled on TXT …
[Ballot discuss]
Holding my own DISCUSS:

Text needs to be created (probably for section 3.1) to better describe the reason this document settled on TXT RR only and therefore why no precedent is set for future use of the TXT RR.
2013-09-07
19 Pete Resnick [Ballot comment]
Clarifications needed regarding size limitations in 3.4, and perhaps some clarifications in 4.6.4.
2013-09-07
19 Pete Resnick [Ballot Position Update] Position for Pete Resnick has been changed to Discuss from Yes
2013-09-07
19 Pete Resnick Ballot has been issued
2013-09-07
19 Pete Resnick [Ballot Position Update] New position, Yes, has been recorded for Pete Resnick
2013-09-07
19 Pete Resnick Created "Approve" ballot
2013-09-04
19 Meral Shirazipour Request for Last Call review by GENART Completed: Ready. Reviewer: Meral Shirazipour.
2013-09-03
19 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2013-09-03
19 Amanda Baber
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-spfbis-4408bis-19.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-spfbis-4408bis-19.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA has a question about the actions requested in this document. In addition, we were only able to initiate the IESG-designated expert review necessary for one action upon completing this review.

IANA understands that, upon approval of this document, there are three actions which IANA must complete.

First, in the Resource Record (RR) TYPEs registry of the Domain Name System (DNS) Parameters page located at:

http://www.iana.org/assignments/dns-parameters

the reference for RRTYPE 99 will be changed to [ RFC-to-be ].

IANA Question -> should the record for RRTYPE 99 be marked OBSOLETE?


Second, in the Permanent Message Header Field Names registry located at:

http://www.iana.org/assignments/message-headers

IANA will register the following, if the registry expert approves:

Header field name: Received-SPF
Protocol: mail
Status: standard
Reference: [ RFC-to-be ]


Third, in the Modifier Names registry in the Sender Policy Framework Parameters registry at:

http://www.iana.org/assignments/spf-parameters

the references for the following modifiers will be changed to [ RFC-to-be ]:

exp
redirect

No other changes are to be made to this registry.


IANA understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.
2013-09-02
19 (System) State changed to Waiting for AD Go-Ahead from In Last Call
2013-08-22
19 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2013-08-22
19 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2013-08-22
19 Tero Kivinen Request for Last Call review by SECDIR is assigned to Phillip Hallam-Baker
2013-08-22
19 Tero Kivinen Request for Last Call review by SECDIR is assigned to Phillip Hallam-Baker
2013-08-19
19 Amy Vezza IANA Review state changed to IANA - Review Needed
2013-08-19
19 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Sender Policy Framework (SPF) for …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard


The IESG has received a request from the SPF Update WG (spfbis) to
consider the following document:
- 'Sender Policy Framework (SPF) for Authorizing Use of Domains in Email,
  Version 1'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-09-02. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Email on the Internet can be forged in a number of ways.  In
  particular, existing protocols place no restriction on what a sending
  host can use as the "MAIL FROM" of a message or the domain given on
  the SMTP HELO/EHLO commands.  This document describes version 1 of
  the Sender Policy Framework (SPF) protocol, whereby ADministrative
  Management Domains (ADMDs) can explicitly authorize the hosts that
  are allowed to use its domain names, and a receiving host can check
  such authorization.

  This document obsoletes RFC4408.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis/ballot/

The following IPR Declarations may be related to this I-D:
https://datatracker.ietf.org/ipr/1698/


2013-08-19
19 Amy Vezza State changed to In Last Call from Last Call Requested
2013-08-19
19 Amy Vezza Last call announcement was changed
2013-08-19
19 Amy Vezza Last call announcement was generated
2013-08-18
19 Pete Resnick Last call was requested
2013-08-18
19 Pete Resnick Ballot approval text was generated
2013-08-18
19 Pete Resnick State changed to Last Call Requested from AD Evaluation
2013-08-18
19 Pete Resnick Last call announcement was changed
2013-08-18
19 Pete Resnick Last call announcement was generated
2013-08-18
19 Scott Kitterman New version available: draft-ietf-spfbis-4408bis-19.txt
2013-08-17
18 Pete Resnick Ballot writeup was changed
2013-08-17
18 Pete Resnick Ballot writeup was changed
2013-08-17
18 Pete Resnick Last call announcement was changed
2013-08-17
18 Pete Resnick Placed on agenda for telechat - 2013-09-12
2013-08-16
18 Scott Kitterman New version available: draft-ietf-spfbis-4408bis-18.txt
2013-08-16
17 S Moonesamy Changed document writeup
2013-08-14
17 Pete Resnick Last call announcement was changed
2013-08-14
17 Pete Resnick Ballot writeup was changed
2013-08-14
17 Pete Resnick Last call announcement was changed
2013-08-14
17 Pete Resnick Last call announcement was generated
2013-08-14
17 Pete Resnick Last call announcement was changed
2013-08-14
17 Pete Resnick Last call announcement was generated
2013-08-14
17 Pete Resnick Last call announcement was generated
2013-08-14
17 Pete Resnick Ballot writeup was changed
2013-08-14
17 Pete Resnick Ballot writeup was generated
2013-07-19
17 Pete Resnick State changed to AD Evaluation from Publication Requested
2013-07-15
17 Amy Vezza
Summary

  S. Moonesamy is the Document Shepherd for this document. Pete Resnick
  is the Responsible Area Director.

  draft-ietf-spfbis-4408bis describes version 1 of …
Summary

  S. Moonesamy is the Document Shepherd for this document. Pete Resnick
  is the Responsible Area Director.

  draft-ietf-spfbis-4408bis describes version 1 of the Sender Policy
  Framework (SPF) protocol, whereby Administrative Management Domains
  can explicitly authorize the hosts that are allowed to use its domain
  names, and a receiving host can check such authorization.

  The working group was chartered to produce a document as a Proposed
  Standard defining the SPF protocol based upon RFC 4408 (Experimental).

Review and Consensus

This document is a product of the SPFBIS working group, and has been
through a large number of revisions including a complete reorganization
of the document.  The working group dealt with a number of controversial
topics.  The following outlines how those were resolved:

    There was an intermediate conclusion about the topic of whether the SPF
    protocol should use the SPF RRTYPE or the TXT resource record.  It was
    followed by an objection.  After discussion of the topic at the IETF 83
    SPFBIS WG session the conclusion reached was that the decision would be
    not to publish RRTYPE 99 and and not to query RRTYPE 99.  The WG
    consensus about the RRTYPE can be described as particularly rough.  The
    topic of obsoleting the SPF RRTYPE generated a lot of controversy near
    the end of the WGLC.  There were a very high number of messages about
    the topic on the SPFBIS mailing list and the DNSEXT mailing list as some
    DNSEXT WG participants were not aware of RFC 6686.
 
    The topic of whether the SPF protocol has to reject mail or not when
    the result of the evaluation is "Fail" was actively discussed.  It
    was determined that it was a matter of local policy.
   
    There was discussion about standardizing the "best guess" heuristics to
    guess possible SPF policies for domains that do not publish an SPF record.
    The WG consensus was not to standardize the heuristics.

    The topic of mail forwarding and mailing lists in respect to the SPF
    protocol was not too controversial in comparison with the other
    controversies.  The WG consensus was to have the document discuss about
    the topic in a non-normative manner.

    There was some controversy about whether the use of macros was a
    security risk and whether to deprecate the PTR feature.  There was a
    formal appeal of the SPFBIS WG chair' interpretation of the charter,
    specifically regarding the removal of "unused" features.  The two
    features in particular which drove the appeal were the PTR feature
    and the local-part macro feature.  These features were not removed
    from the document given that the appeal was denied by the Responsible
    Area Director.

    There was significant discussion about whether to use the
    "Received-SPF:" header field or whether to use the
    "Authentication-Results" header field to record the results of a SPF
    evaluation.  The working group decided to add both header fields in
    the document as they are in common use.

    There was a suggestion to reorganize the document.  It was argued that
    the document had become somewhat bloated with documentation of nuance
    and other text that has nothing to do with defining a protocol and
    enabling interoperability.  This led to a stalemate.  Based on the
    discussion during the SFPBIS WG session at IETF 85 the WG decided to
    proceed with a reorganization of the document while ensuring that the
    reorganization did  not create any text changes apart from moving text
    around.

  There is rough consensus within the SPFBIS WG to publish the document.

  There are multiple existing implementations of the SPF protocol.  The
  document was reviewed by the SPFBIS working group.  Dave Crocker,
  Stuart Gathman, Murray Kucherawy, John Levine,  Hector Santos,
  Andrew Sullivan, Arthur Thisell, and Alessandro Vesely reviewed the
  document.  Simon Perreault helped to clarify the meaning of IPv4 mapped
  IPv6 addresses.  Murray Kucherawy deserves a special mention for his
  contributions.

  The document was reviewed by Cyrus Daboo on behalf of the Applications
  Area Directorate.  Meral Shirazipour reviewed the document for Gen-ART
  and Phillip Hallam-Baker performed the Security Directorate review.

  I suggest further review of the document from a DNS perspective.

Intellectual Property

  The author confirmed that any and all appropriate IPR disclosures
  required for full conformance with the provisions of BCP 78 and
  BCP 79 have already been filed.

  The working group was informed about an IPR disclosure filed for
  RFC 4408 ( https://datatracker.ietf.org/ipr/1698/ ) before the
  WGLC.  There wasn't any noteworthy discussion about the IPR
  disclosure.

Other Points

  There is a downward reference to RFC 1983.

  RFC 5598 is already in the DOWNREF registry.  The US-ASCII reference
  is already used in standards track documents.

  IANA action is requested to update the Resource Record (RR) TYPEs
  registry.  The "Received-SPF:" header field is being added to the
  Permanent Message Header Field Registry.  IANA is requested to
  update the SPF Modifier Registry.  The document does not create
  any IANA registries.

  An automated check of the ABNF in Appendix A was performed.

  Id-nits lists a non-RFC2606-compliant FQDN, six non-RFC5735-compliant
  IPv4 addresses and one instance of a private range IPv4 address.
  These warnings can be ignored.  The warning about CFWS is incorrect.
  The reference to RFC 2671 is intentional;  the document also
  references RFC 6891.

  Some WG participants have mentioned that they may express extreme
  discontent about the decision to obsolete the SPF RRTYPE during
  the Last Call.
2013-07-15
17 Amy Vezza IESG process started in state Publication Requested
2013-07-15
17 (System) Earlier history may be found in the Comment Log for draft-kitterman-4408bis
2013-07-15
17 S Moonesamy Intended Status changed to Proposed Standard from None
2013-07-15
17 S Moonesamy IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2013-07-15
17 S Moonesamy Annotation tag Doc Shepherd Follow-up Underway cleared.
2013-07-15
17 S Moonesamy Changed document writeup
2013-07-14
17 Scott Kitterman New version available: draft-ietf-spfbis-4408bis-17.txt
2013-07-14
16 S Moonesamy IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead
2013-07-14
16 S Moonesamy Annotation tag Doc Shepherd Follow-up Underway set. Annotation tag Revised I-D Needed - Issue raised by WG cleared.
2013-07-02
16 Scott Kitterman New version available: draft-ietf-spfbis-4408bis-16.txt
2013-05-23
15 Scott Kitterman New version available: draft-ietf-spfbis-4408bis-15.txt
2013-05-02
14 Tero Kivinen Request for Early review by SECDIR Completed: Has Nits. Reviewer: Phillip Hallam-Baker.
2013-05-01
14 S Moonesamy IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2013-05-01
14 S Moonesamy Annotation tag Revised I-D Needed - Issue raised by WG set.
2013-04-25
14 Tero Kivinen Request for Early review by SECDIR is assigned to Phillip Hallam-Baker
2013-04-25
14 Tero Kivinen Request for Early review by SECDIR is assigned to Phillip Hallam-Baker
2013-04-16
14 S Moonesamy IETF WG state changed to In WG Last Call from WG Document
2013-04-16
14 S Moonesamy Changed shepherd to S Moonesamy
2013-04-01
14 Scott Kitterman New version available: draft-ietf-spfbis-4408bis-14.txt
2013-03-25
13 Scott Kitterman New version available: draft-ietf-spfbis-4408bis-13.txt
2013-03-16
12 Scott Kitterman New version available: draft-ietf-spfbis-4408bis-12.txt
2013-02-25
11 Scott Kitterman New version available: draft-ietf-spfbis-4408bis-11.txt
2013-02-07
10 Scott Kitterman New version available: draft-ietf-spfbis-4408bis-10.txt
2013-01-15
09 Scott Kitterman New version available: draft-ietf-spfbis-4408bis-09.txt
2012-10-23
08 Cindy Morgan New version available: draft-ietf-spfbis-4408bis-08.txt
2012-09-07
07 Scott Kitterman New version available: draft-ietf-spfbis-4408bis-07.txt
2012-08-22
06 Scott Kitterman New version available: draft-ietf-spfbis-4408bis-06.txt
2012-08-18
05 Scott Kitterman New version available: draft-ietf-spfbis-4408bis-05.txt
2012-08-15
04 Scott Kitterman New version available: draft-ietf-spfbis-4408bis-04.txt
2012-07-05
03 Scott Kitterman New version available: draft-ietf-spfbis-4408bis-03.txt
2012-06-29
02 Scott Kitterman New version available: draft-ietf-spfbis-4408bis-02.txt
2012-06-26
01 Scott Kitterman New version available: draft-ietf-spfbis-4408bis-01.txt
2012-06-23
00 Scott Kitterman New version available: draft-ietf-spfbis-4408bis-00.txt