Subject: [spfbis] Initial version of draft-ietf-spfbis-4408bis

From: Scott Kitterman <[email-masked]>
Date: Sun, 24 Jun 2012 01:32:59 -0400

I've just submitted the -00, but it won't appear until after a manual push.  I 
also reviewed the open tickets and statused them below.  The ones that have 
been incorporated were all either altready done in my pre-WG draft or obvious 
fixes/issues that I didn't think were controversial and it the language changes 
were easy.  I left the fun ones on the table.

Scott K

Ticket #1, RFC 4408 Section 2.5.6 - Temporary errors - language added
Ticket #5, RFC 4408 ambiguities - Reviewed all multiple result tests in the 
test suite.  Sent two to the list for discussion, made two changes, and don't 
believe the rest require changes in 4408bis due to them being in the test 
suite (some are addreesed on other tickets)
Ticket #7, RFC 4408 Downcase result names in spec text and ABNF - There's a 
comment that makes reference to updating the MARF SPF reporting draft, but 
since the ABNF is actually case insensitive, I don't think was actually need 
to do that.
Ticket #9 - RFC 4408 SPF RR type - Did NOT address
Ticket #10 - RFC 4408 rplace Received-SPF with RFC5451 - Did NOT address
Ticket #12 - RFC 4408 Section 9 - Forwarding and helo identities - Did NOT 
address
Ticket #14 - RFC 4408: local-part macro prep for deprecation- Did NOT address
Ticket #15 - RFC 4408: Section 2.2 Requirement to check mail from - Updated 
text
Ticket #16 - RFC 4408: Section 8.1 Add %v macro to ABNF grammar - Fixed
Ticket #18 - RFC 4408: Section 2.5.6 Recommend an SMTP reply code for optional 
PermError rejections - Already fixed in pre-WG draft
Ticket #20 - RFC 4408: Section 4.6.1 unknown-modifier clause is too greedy in 
ABNF - Already fixed in pre-WG draft
Ticket #21 - Already fixed in pre-WG draft
Ticket #22 - Section 2.5.7 PermError on invalid domains after macro expansion 
- Subject of discussion on spfbis - Did NOT address
Ticket #24 - RFC 4408: Reasonable DNS error limits - Did NOT address
Ticket #25 - RFC 4408: Section 4.4 Parallel Query - Did NOT address, will 
probably go away with no action
Ticket #26 - RFC 4408: Should the syntax checking of SPF records be relaxed at 
all - Did NOT address
Ticket #27 - RFC 4408: Should the ptr: mechanism and the %{p} macro be 
deprecated - Marked ptr/'p' deprecated/SHOULD NOT use.
Ticket #29 - RFC 4408: Section 2.5.4 - mark on fail - Did NOT address
Ticket #6 - RFC 4408 Section 10.1 - Processing limits needs clarification and 
reorganization - Did NOT address
Ticket #13 - RFC 4408: Best-Guess SPF - Did NOT address
Ticket #8 - RFC 4408 Mixed use of RFC2119 words - Fixed.
Ticket #17 - RFC 4408: Section 7 Received-SPF examples use incorrect syntax - 
Already fixed in pre-WG draft
Ticket #19 - RFC 4408: Section 7 Received-SPF examples use incorrect syntax - 
Already fixed in pre-WG draft
Ticket#2 - RFC 4408 Section B.3 - Errata #2250 - Already fixed in pre-WG draft
Ticket #3 - RFC 4408 - Errata #99 - Fixed or made OBE due to other changes in 
pre-WG draft
Ticket #23 - RFC 4408: Typos - Already fixed in pre-WG draft

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 25 Jun 2012 13:19:21 +0200

> Ticket #1, RFC 4408 Section 2.5.6 - Temporary errors - language added

Do you mean the text appended to Section 4.4?  It looks rather
obscure, as it tries to convey a complex algorithm using too few
words.  (I don't think that referring to RFC 6555 would be useful,
since the algorithm described there is about address families.)

What exactly are we suggesting mail servers to do?

> suite (some are addressed on other tickets)
> Ticket #10 - RFC 4408 replace Received-SPF with RFC5451 - Did NOT address

I hope the ban against discussing reject-on-fail will be revoked.

> Ticket #15 - RFC 4408: Section 2.2 Requirement to check mail from - Updated 

The changed sentence looks garbled:

 SPF clients MUST check the "MAIL FROM" identity if a completed "HELO"
 check.  SPF clients check has not reached a definitive policy result.

One of the possible interpretations is that a "pass" on helo is
enough, i.e. that the helo identity prevails, in some sense.  That
works for me.  However, the example in the last but two paragraph of
Section 2.4 ("if the reverse-path was null") seems to imply the opposite.

> deprecated - Marked ptr/'p' deprecated/SHOULD NOT use.

Works for me.  For clarity, I'd suggest to also change the relevant
entries in the mechanism list (Section 5) and in the macro list
(Section 8.1) to read, e.g.:

    ptr: DEPRECATED
and
    p = the validated domain name of <ip>: DEPRECATED

Possibly, even the title of Section 5.5 can be changed that way.

How about adding a short paragraph to Section 1.3 for the term
"DEPRECATED"?

A closed parenthesis is missing in

 using IPv4 mechanisms (i.e. "ip4" and "a".

> Ticket #29 - RFC 4408: Section 2.5.4 - mark on fail - Did NOT address

See above

> Ticket #8 - RFC 4408 Mixed use of RFC2119 words - Fixed.

Does this have to be done thoroughly?  In that case, there is:

 rejecting E-Mail from invalid domains should be considered.

And there's a typo in a fix:

 "include" directive is generally be more appropriate.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 25 Jun 2012 13:41:41 -0400

I seem to have neglected to mention it in my summary, but I also removed X- 
from the draft in anticipation of BCP 178, RFC 6648 that's just been published 
(Deprecating the "X-" Prefix and Similar Constructs in Application Protocols).

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 25 Jun 2012 11:12:00 -0700

> were easy.  I left the fun ones on the table.
A few cursory observations until I carve out time for a full review:

RFC4871 is obsolete; should be RFC6376
RFC2821 is obsolete; should be RFC5321
RFC2822 is obsolete; should be RFC5322
RFC4234 is obsolete; should be RFC5234

In 12.1, it's no longer a "new" record type.

In 12.2, shouldn't the defining document for Received-SPF be RFC4408?

The document refers to messages as "E-Mail".  I'll pre-empt Dave by saying
this should probably changed throughout to "email".

A bunch of the terminology around roles in email can probably refer to
RFC5598, especially when it comes to styles of forwarding since that's a
sensitive topic with respect to SPF.  For example, Section 9.3 of this
document could make use of some of the terms and discussions in that
document to paint a clear picture of what's going on and why it causes what
are perceived as false negatives.

More soon...

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 25 Jun 2012 14:38:29 -0400

> since the algorithm described there is about address families.)

Yes.  

I wasn't trying to specify what I would call an algorithm.  There isn't an 
interoperability gain associated with everyone doing this identically.  All we 
need to communicate is "You can treat repeated SERVFAIL for the same domain as 
permerror if you prefer."  Suggestions welcome on text.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 25 Jun 2012 14:46:26 -0400

>  check.  SPF clients check has not reached a definitive policy result.

Yes.  What I meant to say was:

   SPF clients MUST check the "MAIL FROM" identity if a completed "HELO"
   check has not reached a definitive policy result by applying the
   check_host() function to the "MAIL FROM" identity as the <sender>.

Fixed locally.

> Section 2.4 ("if the reverse-path was null") seems to imply the opposite.

That is what I meant to convey.  In software I develop one of the few ways I 
explicitly deviate from RFC 4408 is to not bother with checking Mail From if 
there's already a conclusion to reject based on HELO.  It just wastes cycles.

I don't think 2.4 implies the opposite.  I think it applies if you are 
checking Mail From, but doesn't insist that you do so.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 25 Jun 2012 15:01:42 -0400

> Possibly, even the title of Section 5.5 can be changed that way.

Done locally.

> How about adding a short paragraph to Section 1.3 for the term

Is this really needed?  I would have thought it's a sufficiently standard term 
we don't need it, perhaps I'm wrong.  My definition is, imprecisely stated, 
"Continuing to use this is a bad idea.  It's still supported for now, but may 
be removed without warning in the future."

If people do think this is needed, suggestions on more precisely crafted text 
are welcome.

>  using IPv4 mechanisms (i.e. "ip4" and "a".

Fixed.

Thanks,

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 25 Jun 2012 15:04:40 -0400

>  "include" directive is generally be more appropriate.

Thanks.  Cleared that up locally.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 26 Jun 2012 12:47:54 +0200

On Mon 25/Jun/2012 20:38:29 +0200 Scott Kitterman wrote:
> permerror if you prefer."

Servers don't have to behave identically, but consistently.  The risk
of playing sorcerer's apprentice with that is to obtain undesired,
non-compliant behavior.  But I don't think DNS servers would go off
the beaten track by using negative caching parameters far from those
specified by RFC 2308.

OTOH, it seems to be a good idea for a mail server to keep track of
the domain names that it interacts with, in general.  This case is so
marginal --because both the SPF RRTYPE and reject-on-fail are such--
that it doesn't justify the creation of a database.  However, if a
server already uses one, it may add a couple of fields for treating
this case.

> Suggestions welcome on text.

Two:

s/Alternately/Alternatively/.

Add an explanation, such as:

 That is not intended to save further queries, which MUST  be done
 according to RFC 2308, but to return a permanent negative completion
 reply code to the client, instead of a transient one, thereby
 shortening the queue time of messages that cannot be accepted.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 26 Jun 2012 12:48:48 +0200

> there's already a conclusion to reject based on HELO.  It just wastes cycles.

You are apparently assuming that the result is failure irrespectively
of the result of checking the other identity.  We have no provisions
for computing a global result from the separate results of checking
both identities.  IMHO we should.  However, the results table looks
ugly even if I only put the results for which I have an argument for.
 Can you fix or complete it?

  HELO     | MAIL FROM |
-----------+-----------+-----
  pass     | pass      | pass
  SNN*     | pass      | pass
  fail     | pass      | fail
  ERR**    | pass      | ?
  pass     | SNN*      | ?
  SNN*     | SNN*      | SNN*
  fail     | SNN*      | fail
  ERR**    | SNN*      | ?
  pass     | fail      | fail***
  SNN*     | fail      | fail
  fail     | fail      | fail
  ERR**    | fail      | ?
  pass     | ERR**     | ?
  SNN*     | ERR**     | ?
  fail     | ERR**     | fail
  ERR**    | ERR**     | ERR**

*   SNN = softfail, neutral, or none
**  ERR = temperror or permerror
*** this failure shouldn't trigger rejection, IMHO

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 26 Jun 2012 09:17:53 -0400

> RFC4871 is obsolete; should be RFC6376

Removed this entirely as it's not referenced anywhere anymore.

> RFC4234 is obsolete; should be RFC5234

Updated.

> In 12.2, shouldn't the defining document for Received-SPF be RFC4408?

Both fixed.  Should the information about the modifier registry be copied from 
RFC 6652 into the IANA considerations for 4408bis and have 4408bis update 
6652?

> this should probably changed throughout to "email".

Done.

> are perceived as false negatives.

I agree.  This will take a bit of work, so we should probably have an issue to 
track this if it doesn't fit an existing one.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 26 Jun 2012 09:34:17 -0400

On Tuesday, June 26, 2012 12:48:48 PM Alessandro Vesely wrote:
> > That is what I meant to convey.  In software I develop one of the few ways
> > I explicitly deviate from RFC 4408 is to not bother with checking Mail
> > From if there's already a conclusion to reject based on HELO.  It just
> > wastes cycles.

This is not by accident.  The two sets of results have different semantics and 
can be used for local policy in different ways.  RFC 4408 specified the minimum 
interaction between the two identities for interoperability (If Mail From is 
null, use HELO in it's place) and no more.  The rest of the integration 
between the results for the two identities is left to local policy.

Unless we decide to go further into receiver policy in 4408bis than RFC 4408 
did (and I recommend we don't) then I think specifying the integration of the 
two identities is not something we should do.  It is not unheard of to take 
different local policy actions for a particular SPF result for Mail From or 
HELO.  As an example, I maintain software that (by default - it's all 
configurable) will reject on SPF fail for Mail From or on SPF 
fail/softfail/neutral for HELO/EHLO.  An integrated result would be counter-
productive for me.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 26 Jun 2012 09:41:49 -0400

On Tuesday, June 26, 2012 12:47:54 PM Alessandro Vesely wrote:
> > interoperability gain associated with everyone doing this identically. 
> > All we need to communicate is "You can treat repeated SERVFAIL for the
> > same domain as permerror if you prefer."
> 

The difference between temperror deferral and permerror reject is the queue 
life of the sending MTA in cases where the source of the temperror isn't going 
to resolve.  Since there are cases where SERVFAIL results are effectively 
permanent, using this option lets the sender know much sooner their message 
didn't make it.  It's not an essential part of the protocol, but opening the 
options slightly to allow for this efficiency for senders that want to use it.

>  shortening the queue time of messages that cannot be accepted.

Incorporated locally.  Thanks,

Scott K